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Considerations for Deploying the Rapid Acquisition of 
Multicast RIP Sessions (RAMS) Method 


Abstract 


The Rapid Acquisition of Multicast RIP Sessions (RAMS) solution is a 
method based on RIP and the RIP Control Protocol (RICP) that enables 
an RTP receiver to rapidly acquire and start consuming the RIP 
multicast data. Upon a request from the RTP receiver, an auxiliary 
unicast RTP retransmission session is set up between a retransmission 
server and the RTP receiver, over which the reference information 
about the new multicast stream the RTP receiver is about to join is 
transmitted at an accelerated rate. This often precedes, but may 
also accompany, the multicast stream itself. When there is only one 
multicast stream to be acquired, the RAMS solution works ina 
straightforward manner. However, when there are two or more 
multicast streams to be acquired from the same or different multicast 
RTP sessions, care should be taken to configure each RAMS session 
appropriately. This document provides example scenarios and 
discusses how the RAMS solution could be used in such scenarios. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6659. 
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1. Introduction 


The Rapid Acquisition of Multicast RIP Sessions (RAMS) solution is a 
method based on RIP and the RIP Control Protocol (RICP) that enables 
an RTP receiver to rapidly acquire and start consuming the RIP 
multicast data. Through an auxiliary unicast RIP retransmission 
session [RFC4588], the RIP receiver receives reference information 
about the new multicast stream it is about to join. This often 
precedes, but may also accompany, the multicast stream itself. The 
RAMS solution is documented in detail in [RFC6285]. 
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The RAMS specification [RFC6285] has provisions for concurrently 
acquiring multiple streams inside a multicast RIP session. However, 
the RAMS specification does not discuss scenarios where an RIP 
receiver makes use of the RAMS method to rapidly acquire multiple and 
associated multicast streams in parallel, or where different RIP 
sessions are part of the same Source-Specific Multicast (SSM) 
session. The example presented in Section 8.3 of [RFC6285] addresses 
only the simple case of an RIP receiver rapidly acquiring only one 
multicast stream to explain the protocol details. 


There are certain deployment models where a multicast RIP session 
might have two or more multicast streams associated with it. There 
are also cases where an RIP receiver might be interested in acquiring 
one or more multicast streams from several multicast RIP sessions. 
Close coordination is required for multiple RAMS sessions 
simultaneously started by an RIP server, where each session is 
initiated with an individual RAMS Request message to a different 
feedback target. In this document, we present scenarios from real- 
life deployments and discuss how the RAMS solution could be used in 
such scenarios. 


2. Background 


In the following discussion, we assume that there are two RIP streams 
(1 and 2) that are in some manner associated with each other. These 
could be audio and video elementary streams for the same TV channel, 
or they could be an MPEG2 Transport Stream (that has audio and video 
multiplexed together) and its Forward Error Correction (FEC) stream. 


An SSM session is defined by its (distribution) source address and 
(destination) multicast group, and there can be only one feedback 
target per SSM session [RFC5760]. So, if the RIP streams are 
distributed by different sources or over different multicast groups, 
they are considered different SSM sessions. While different SSM 
sessions can normally share the same feedback target address and/or 
port, RAMS requires each unique feedback target (i.e., the 
combination of address and port) to be associated with at most one 
RTP session (See Section 6.2 of [RFC6285]). 


Two or more multicast RTP streams can be transmitted in the same RTP 
session (e.g., in a single UDP flow). This is called Synchronization 
Source (SSRC) multiplexing. In this case, (de)multiplexing is done 
at the SSRC level. Alternatively, the multicast RTP streams can be 
transmitted in different RTP sessions (e.g., in different UDP flows), 
which is called session multiplexing. In practice, there are 
different deployment models for each multiplexing scheme. 
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Generally, to avoid complications in RICP reports, it is suggested 
that two different media streams with different clock rates use 
different SSRCs or be carried in different RIP sessions. Some of the 
fields in RAMS messages might depend on the clock rate. Thus, in a 
single RIP session, RIP streams carrying payloads with different 
clock rates need to have different SSRCs. Since RIP streams with 
different SSRCs do not share the sequence numbering, each stream 
needs to be acquired individually. 


In the remaining sections, only the relevant portions of the Session 
Description Protocol (SDP) descriptions [RFC4566] will be provided. 
For an example of a full SDP description, refer to Section 8.3 of 


[RFC6285]. 
3. Example Scenarios 
3.1. Scenario #1: Two Multicast Groups 


This is the scenario for session multiplexing where RIP streams 1 and 
2 are transmitted over different multicast groups. A practical use 
case is where the first and second SSM sessions carry the primary 
video stream and its associated FEC stream, respectively. 


An individual RAMS session is run for each of the RTP streams that 
require rapid acquisition. Each requires a separate RAMS Request 
message to be sent. These RAMS sessions can be run in parallel. If 
they are, the RTP receiver needs to pay attention to using the shared 
bandwidth appropriately among the two unicast bursts. As explained 
earlier, there has to be a different feedback target for these two 
SSM sessions. 


v=0 

o=ali 1122334455 1122334466 IN IP4 rams.example.com 
S=RAMS Scenarios 

t=0 0 

a=group:FEC-FR Channell Video Channell FEC 

m=video 40000 RTP/AVPF 96 

c=IN IP4 233.252.0.1/127 

a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 
a=rtcp:41000 IN IP4 192.0.2.1 

a=ssrc:1l cname:chl_video@example.com 

a=mid:Channell Video 

m=application 40000 RTP/AVPF 97 

c=IN IP4 233.252.0.2/127 

a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 
a=rtcp:42000 IN IP4 192.0.2.1 

a=ssrc:2 cname:chl_fec@example.com 
a=mid:Channell FEC 
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Note that the multicast destination ports in the above SDP do not 
matter, and they could be the same or different. The "FEC-FR" 
grouping semantics are defined in [RFC5956]. 


3.2. Scenario #2: One Multicast Group 


Here, RTP streams 1 and 2 are transmitted over the same multicast 
group with different destination ports. A practical use case is 
where the SSM session carries the primary video and audio streams, 
each destined to a different port. 


The RAMS Request message sent by an RIP receiver to the feedback 
target could indicate the desire to acquire all or a subset or one of 
the available RTP streams. Thus, both the primary video and audio 
streams can be acquired rapidly in parallel. Or, the RIP receiver 
can acquire only the primary video or audio stream, if desired, by 
indicating the specific SSRC in the request. Compared to the 
previous scenario, the only difference is that in this case the join 
times for both streams need to be coordinated as they are delivered 
in the same multicast session. 


v=0 

o=ali 1122334455 1122334466 IN IP4 rams.example.com 
S=RAMS Scenarios 

t=0 0 

m=video 40000 RIP/AVPF 96 

c=IN IP4 233.252.0.1/127 

a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 
a=rtcp:41000 IN IP4 192.0.2.1 

a=ssrc:1 cname:chl_video@example.com 

a=mid:Channell Video 

m=audio 40001 RTP/AVPF 97 

c=IN IP4 233.252.0.1/127 

a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 
a=rtcp:41000 IN IP4 192.0.2.1 

a=ssrc:2 cname:chl_audio@example.com 
a=mid:Channell_Audio 


Note that the destination ports in "m" lines need to be distinct per 
[RFC5888]. 


If RTP streams 1 and 2 share the same distribution source, then there 
is only one SSM session, which means that there can be only one 
feedback target (as shown in the SDP description above). This 
requires RIP streams 1 and 2 to have their own unique SSRC values 
(also as shown in the SDP description above). If RIP streams 1 and 2 
do not share the same distribution source, meaning that their 
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respective SSM sessions can use different feedback target transport 
addresses, then their SSRC values do not have to be different from 
each other. 


3.3. Scenario #3: SSRC Multiplexing 


This is the scenario for SSRC multiplexing where both RIP streams are 
transmitted over the same multicast group to the same destination 
port. This is a less practical scenario, but it could be used where 
the SSM session carries both the primary video and audio stream, 
destined to the same port. 


Similar to scenario #2, both the primary video and audio streams can 
be acquired rapidly in parallel. Or, the RIP receiver can acquire 
only the primary video or audio stream, if desired, by indicating the 
specific SSRC in the request. In this case, there is only one 
distribution source and the destination multicast address is shared. 
Thus, there is always one SSM session and one feedback target. 


v=0 

o=ali 1122334455 1122334466 IN IP4 rams.example.com 
S=RAMS Scenarios 

t=0 0 

m=video 40000 RTP/AVPF 96 97 

c=IN IP4 233.252.0.1/127 

a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 
a=rtcp:41000 IN IP4 192.0.2.1 

a=ssrc:1l cname:chl_video@example.com 

a=ssrc:2 cname:chl_audio@example.com 

a=mid:Channell 


3.4. Scenario #4: Payload-Type Multiplexing 
This is the scenario for payload-type multiplexing. 


In this case, instead of two, there is only one RTP stream (and one 
RTP session) carrying both payload types (e.g., media payload and its 
FEC data). While this scheme is permissible per [RFC3550], it has 
several drawbacks. For example, RIP packets carrying different 
payload formats will share the same sequence numbering space, and the 
RAMS operations will not be able to be applied based on the payload 
type. For other drawbacks and details, see Section 5.2 of [RFC3550]. 
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4. Feedback Target and SSRC Signaling Issues 


The RAMS protocol uses the common packet format from [RFC4585], which 
has a field to signal the media sender SSRC. The SSRCs for the RIP 
streams can be signaled out-of-band in the SDP or could be learned 
from the RIP packets once the transmission starts. In RAMS, the 
latter cannot be used. 


Signaling the media sender SSRC value helps the feedback target 
correctly identify the RIP stream to be acquired. If a feedback 
target is serving multiple SSM sessions on a particular port, all the 
RIP streams in these SSM sessions are supposed to have a unique SSRC 
value. However, this is not an easy requirement to satisfy. Thus, 
the RAMS specification forbids having more than one RIP session 
associated with a specific feedback target on a specific port. 


5. FEC during RAMS and Bandwidth Issues 


Suppose that RIP stream 1 denotes the primary video stream that has a 
bitrate of 10 Mbps and RIP stream 2 denotes the associated FEC stream 
that has a bitrate of 1 Mbps. Also assume that the RIP receiver 
knows that it can receive data at a maximum bitrate of 22 Mbps. SDP 
can specify the bitrate ("b=" line in kbps) of each media session 
(per "m" line). 


Note that RAMS can potentially congest the network temporarily. 
Refer to [RFC6285] for a detailed discussion. 


5.1. Scenario #1 


This is the scenario for session multiplexing where RTP streams 1 and 
2 are transmitted over different multicast groups. 


This is the preferred deployment model for FEC [RFC6363]. Having FEC 
in a different multicast group provides two flexibility points: RTP 
receivers that are not FEC capable can receive the primary video 
stream without FEC, and RTP receivers that are FEC capable can decide 
to not receive FEC during the rapid acquisition (but still start 
receiving the FEC stream after the acquisition of the primary video 
stream has been completed). 
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v=0 

o=ali 1122334455 1122334466 IN IP4 rams.example.com 
S=RAMS Scenarios 

t=0 0 

a=group:FEC-FR Channell_Video Channell_FEC 

m=video 40000 RIP/AVPF 96 

c=IN IP4 233.252.0.1/127 

a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 
a=rtcp:41000 IN IP4 192.0.2.1 

a=rtpmap:96 MP2T/90000 

b=TIAS:10000 

a=ssrc:l1 cname:chl_video@example.com 
a=mid:Channell_Video 

m=application 40000 RTP/AVPF 97 

c=IN IP4 233.252.0.2/127 

a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 
a=rtcp:42000 IN IP4 192.0.2.1 

a=rtpmap:97 1d-interleaved-parityfec/90000 
b=TIAS:1000 

a=ssrc:2 cname:chl_fec@example.com 
a=mid:Channell_FEC 


If the RTP receiver does not want to receive FEC until the 
acquisition of the primary video stream is completed, the total 
available bandwidth can be used for faster acquisition of the primary 
video stream. In this case, the RTP receiver can request a Max 
Receive Bitrate of 22 Mbps in the RAMS Request message for the 
primary video stream. Once RAMS has been completed, the RTP receiver 
can join the FEC multicast session, if desired. 


If the RTP receiver wants to rapidly acquire both primary and FEC 
streams, it needs to allocate the total bandwidth among the two RAMS 
sessions and indicate individual Max Receive Bitrate values in each 
respective RAMS Request message. Since less bandwidth will be used 
to acquire the primary video stream, the acquisition of the primary 
video session will take a longer time on the average. 


While the RTP receiver can update the Max Receive Bitrate values 


during the course of the RAMS session, this approach is more error- 
prone, due to the possibility of losing the update messages. 
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5.2. Scenario #2 


Here, RIP streams 1 (primary video) and 2 (FEC) are transmitted over 
the same multicast group with different destination ports. This is 
not a preferred deployment model. 


v=0 

o=ali 1122334455 1122334466 IN IP4 rams.example.com 
S=RAMS Scenarios 

t=0 0 

a=group:FEC-FR Channell Video Channell_FEC 

m=video 40000 RIP/AVPF 96 

c=IN IP4 233.252.0.1/127 

a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 
a=rtcp:41000 IN IP4 192.0.2.1 

a=rtpmap:96 MP2T/90000 

b=TIAS:10000 

a=ssrc:1 cname:chl_video@example.com 
a=mid:Channell_Video 

m=application 40001 RTP/AVPF 97 

c=IN IP4 233.252.0.1/127 

a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 
a=rtcp:41000 IN IP4 192.0.2.1 

a=rtpmap:97 1d-interleaved-parityfec/90000 
b=TIAS:1000 

a=ssrc:2 cname:chl_fec@example.com 
a=mid:Channell_FEC 


The RAMS Request message sent by an RTP receiver to the feedback 
target could indicate the desire to acquire all or a subset or one of 
the available RIP streams. Thus, both the primary video and FEC 
streams can be acquired rapidly in parallel sharing the same 
available bandwidth. Or, the RTP receiver can acquire only the 
primary video stream by indicating its specific SSRC in the request. 
In this case, the RTP receiver can first acquire the primary video 
stream at the full receive bitrate. But, upon the multicast join, 
the available bandwidth for the burst drops to 11 Mbps instead of 

12 Mbps. Regardless of whether FEC is desired or not by the RTP 
receiver, its bitrate needs to be taken into account once the RTP 
receiver joins the SSM session. 
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5.3. Scenario #3 


This is the scenario for SSRC multiplexing where both RIP streams are 
transmitted over the same multicast group to the same destination 
port. 


v=0 

o=ali 1122334455 1122334466 IN IP4 rams.example.com 
s=RAMS Scenarios 

t=0 0 

m=video 40000 RIP/AVPF 96 97 

c=IN IP4 233.252.0.1/127 

a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 
a=rtcp:41000 IN IP4 192.0.2.1 

a=rtpmap:96 MP2T/90000 

a=rtpmap:97 1d-interleaved-parityfec/90000 
a=fmtp:97 L=10; D=10; repair-window=200000 

a=ssrc:1l cname:chl_video@example.com 

a=ssrc:2 cname:chl_fec@example.com 

b=TIAS:11000 

a=mid:Channell 


Similar to scenario #2, both the primary video and audio streams can 
be acquired rapidly in parallel. Or, the RIP receiver can acquire 
only the primary video stream, if desired, by indicating its specific 
SSRC in the request. 


Note that based on the "a=fmtp" line for the FEC stream, it could be 
possible to infer the bitrate of this FEC stream and set the Max 
Receive Bitrate value accordingly. 

6. Security Considerations 
Because this document describes deployment scenarios for RAMS, all 
security considerations are specified in the RAMS specification 
[RFC6285]. 
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